Systems and methods for using information from wearable devices

ABSTRACT

Systems and methods for the of use information from application programming interfaces on wearable devices in third party applications are provided. A system comprising a user device, data storage, an application programming interface and an application is provided. In this system, there is a user device that includes a health monitor. The health monitor includes sensors and associated software that enable it to obtain health information about the wearer of the user device. In this system, there is data storage on the user device that stores the health information as user health data. In this system, there is an application programming interface on the user device that enables the health monitor to share the user health data with other applications executing on the user device.

FIELD OF THE INVENTION

The present disclosure generally relates to wearable devices and, inparticular, to using information from application programming interfaceson wearable devices in third party applications for a different purpose.

BACKGROUND

Consumers are increasingly adopting electronic payment methods, such ascredit cards and debit cards, for purchases, wire transfers, bill pay orany other financial transactions. Consumers will commonly carry at leastone credit or debit card, and often consumers carry more than one.Consumers may prefer to use credit or debit cards for reasons ofconvenience, to earn rewards based on spending, to simplify budgetingthrough the receipt of a monthly statement, or to avoid carrying largeamounts of cash. In many areas, credit or debit card transactionsoutnumber cash transactions.

At the same time, the widespread use of communication devices, such assmart phones, smart watches, laptop computers, and tablets, make dataincreasingly accessible, including financial information such as accountbalances and purchase activity, wire transfers, bill pay or any otherfinancial transactions. The availability of these devices createsexpectations for consumers that their data will be easily accessible athome, outside the home, and on mobile devices.

In view of these trends, data security is increasingly important in manyareas, and protecting financial or other sensitive data is a particularconcern. Despite large investments in developing, implementing, andmaintaining security measures, data theft and fraud causes millions, ifnot billions, of losses annually. Any organization handling sensitivedata, financial or otherwise, incurs data security costs and risksliability for theft or other losses due to breaches of data security. Inaddition to monetary costs, data security breaches erode user confidencein a business, and a large or otherwise notable breach often attractssignificant public attention.

Accordingly, there are significant, and competing, needs to safeguardsensitive data while ensuring ready access by authorized users.

SUMMARY

The disclosed subject matter is directed to systems and methods forusing information from application programming interfaces on wearabledevices in third party applications for a different purpose that satisfythese needs.

One embodiment of the present disclosure is a system comprising a userdevice, data storage, an application programming interface and anapplication. In this system, there is a user device that includes ahealth monitor. The health monitor includes sensors and associatedsoftware that enable it to obtain health information about the wearer ofthe user device. In this system, there is data storage on the userdevice that stores the health information as user health data. In thissystem, there is an application programming interface on the user devicethat enables the health monitor to share the user health data with otherapplications executing on the user device. In this system, there is anapplication that executes a query on the user device to obtain a userdevice identifier and the user health data. Using the user health data,the application determines the presence or absence of requisite healthdata. The application transmits the user device identifier and a signalindicating the presence or absence of the requisite health data to aserver. Upon receipt of the user device identifier and signal indicatingthe presence or absence of the requisite health data, the serveridentifies a user account based on the user device identifier and eitherenables or disables transaction authentication. The server enablestransaction authentication if the signal indicates the presence ofhealth data. Alternatively, the server disables transactionauthentication if the signal indicates the absence of health data.

In an example method according to the disclosure, user accounts arestored in a database of a backend system. Each user account includesuser account information that includes information to identify theaccount holder, an account holder wearable device identifier, and aflag. The flag indicates whether transactions are to be approved ordenied based on the respective presence or absence of a vital sign ofthe account holder. The vital sign is detected by a wearable deviceidentified by the account holder wearable device identifier. Anapplication is provided for execution on the wearable device. Thewearable device includes a health monitor with an applicationprogramming interface. Via the application programming interface, theapplication queries the wearable device to obtain a wearable deviceidentifier and health data. The health data indicates the presence orabsence of a vital sign of the wearer of the wearable device. Theapplication wirelessly transmits the wearer's wearable device identifierand health data to the backend system. The backend system receives thewearer's wearable device identifier and health data that indicates thepresence or absence of the wearer's vital sign. Using a processor at thebackend system, it is determined whether the wearer's wearable deviceidentifier matches the account holder wearable device identifier. If thewearer's wearable device identifier matches the account holder wearabledevice identifier, then the processor at the backend system is used toaccess the account holder user account and set the flag that is storedin the account holder user account. The flag indicates whethertransactions are to be approved or denied based on the received healthdata that indicates the presence or absence of the wearer's vital sign.

Further, an example system according to various embodiments comprises awireless wearable device communication interface, a transactionprocessor, a database, and a transaction request communicationinterface. In this system, the wireless wearable device communicationinterface communicates, via a network, with a wearable device to receivea wearable device identifier and a signal. The wearable devices has thewearable device identifier and the signal. The signal indicates whetherthe wearable device is detecting a vital sign of the wearer of thewearable device. In this system, the transaction processor approves ordenies transaction requests. In this system, the database stores aplurality of user accounts. Each user account includes information thatidentifies the account holder, an account holder wearable deviceidentifier, and a user preference indicator. The user preferenceindicator indicates whether the transaction processor is to approve ordeny a requested based on the respective presence or absence of a vitalsign of the account holder. This presence or absence is detected by thewearable device identified by the account holder wearable deviceidentifier. In this example system, the transaction requestcommunication interface receives a transaction request from a point ofsale terminal. When the transaction request communication interfacereceives the transaction request from the point of sale terminal, thetransaction processor identifies a user account. The user account isidentified based on information received with the user account. Thetransaction processor queries the account holder user account todetermine whether user preference indicator stored in the account holderuser account indicates whether to approve or deny the transaction. Thetransaction processor transmits, based on the query result, a signal,via the transaction request communication interface, approving ordenying the transaction to the point of sale terminal. The wearabledevice includes an application that queries, via an applicationprogramming interface, the wearable device to obtain a wearable deviceidentifier and signal. The signal indicates whether the wearable deviceis detecting a vital sign of the wearer of the wearable device. Theapplication wirelessly transmits the wearable device identifier andsignal to the wireless wearable device communication interface.

These and other features, aspects and advantages of the disclosedsubject matter are explained in greater detail with reference tospecific example embodiments that are illustrated in the followingdescription, appended claims, and accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of a system for using a wearable device, accordingto an example embodiment.

FIG. 2 is a diagram of a system for using a wearable device, accordingto an example embodiment.

FIG. 3 is a diagram of a system for using a user device, according to anexample embodiment.

FIG. 4 is a diagram of a system for using a user device, according to anexample embodiment.

FIG. 5 is a flowchart illustrating a method for using a user device,according to an example embodiment.

FIG. 6 is a flowchart illustrating a method for using a user device,according to an example embodiment.

FIG. 7 is a flowchart illustrating a method for using a user device,according to an example embodiment.

FIG. 8 is a flowchart illustrating a method for using a user device,according to an example embodiment.

FIG. 9 is a flowchart illustrating a method for using a user device,according to an example embodiment.

FIG. 10 is a flowchart illustrating a method for using a user device,according to an example embodiment.

FIG. 11 is a flowchart illustrating a method for using a user device,according to an example embodiment.

FIG. 12 is a flowchart illustrating a method for using a user device,according to an example embodiment.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

The following description of embodiments provides non-limitingrepresentative examples referencing numerals to particularly describefeatures and teachings of different aspects of the invention. Theembodiments described should be recognized as capable of implementationseparately, or in combination, with other embodiments from thedescription of the embodiments. A person of ordinary skill in the artreviewing the description of embodiments should be able to learn andunderstand the different described aspects of the invention. Thedescription of embodiments should facilitate understanding of theinvention to such an extent that other implementations, not specificallycovered but within the knowledge of a person of skill in the art havingread the description of embodiments, would be understood to beconsistent with an application of the invention.

FIG. 1 is a diagram of a system 100 for using a wearable device 102,according to an example embodiment. Wearable device 102 may be anyelectronic device that may be worn on a body, implanted, incorporatedinto an item of clothing or an accessory or into a living or workingenvironment, such as a fitness tracker, a smartwatch, glasses, shirt,pants, shoes, gloves, necklaces, earrings, ear pieces, headsets,internet of things (IoT) devices, and other similar devices. Forexample, wearable device 102 may be an Apple Watch®, a FitBit®, a heartrate monitor that a user wears while riding a Peloton® bike, and anyother similar device.

Wearable device 102 may include a sensor 104, an application 106 and acommunication interface 108. Sensor 104 may be capable of determiningsome kind of health data, for example, vital signs like heart rate,blood pressure, glucose or other health data.

As will be described in more detail below, wearable device 102 mayinclude software and interfaces that enable application 106 to obtaininformation, such as health-related and/or vital sign information, fromsensor 104. Application 106 may be one or more applications capable ofreceiving health data from sensor 104 and sending a signal indicatingthe absence or presence of health data from sensor 104 to a server 110using communication interface 108. Application 106 and server 110 may beconfigured to use health data for a different purpose. For example,health data may be used to authenticate a transaction, such as payment,credit, authorization, membership, or access.

Communication interface 108 may facilitate data communication betweenwearable device 102 and server 110 and may occur over one or morenetworks (not shown), such as one or more of a fiber optics network, apassive optical network, a cable network, an Internet network, asatellite network, a wireless local area network (LAN), a Global Systemfor Mobile Communication, a Personal Communication Service, a PersonalArea Network, Wireless Application Protocol, Multimedia MessagingService, Enhanced Messaging Service, Short Message Service, TimeDivision Multiplexing based systems, Code Division Multiple Access basedsystems, Digital-Advanced Mobile Phone Service (D-AMPS), Wi-Fi, FixedWireless Data, IEEE 802.11b, 802.15.1, 802.11n and 802.11g, Bluetooth,near-field communication (NFC), Radio Frequency Identification (RFID),and/or the like. In addition, the network may include, withoutlimitation, telephone lines, fiber optics, IEEE Ethernet 902.3, a widearea network, a wireless personal area network, a LAN, or a globalnetwork such as the Internet. In addition, the network may support anInternet network, a wireless communication network, a cellular network,or the like, or any combination thereof.

Communication interface 108 may communicate using a network that mayfurther include one network, or any number of the exemplary types ofnetworks mentioned above, operating as a stand-alone network or incooperation with each other. The network may utilize one or moreprotocols of one or more network elements to which they arecommunicatively coupled. The network may translate to or from otherprotocols to one or more protocols of network devices. The network maycomprise a plurality of interconnected networks, such as, for example,the Internet, a service provider's network, a cable television network,corporate networks, such as credit card association networks, and homenetworks.

Server 110 may be one or more servers in a client—server system (notshown), which may be a distributed application structure on a networkthat manages tasks or workloads between the providers of a resource orservice, called servers, and service requesters, called clients. Forexample, in a banking or credit card system for making a purchase, wiretransfer, bill pay or any other financial transaction, application 106may act as a client and server 110 may act as a backend server.Application 106 may request a resource or service from server 110 andthen make a payment. For such requests and payments, application 106 andserver 110 may use one or more applications, application programminginterfaces, web services platform-based services, and/or cloud computingservices.

Further, when a user is wearing wearable device 102, the payment may beapproved and when the user is not wearing wearable device 102, thepayment may be denied. Application 106 may determine whether the user iswearing, for example, a heart rate monitor by checking whether sensor104 is reading heart rate data and then use communication interface 108to send a signal to server 110 indicating whether the user is wearingthe heart rate monitor. The user may set up or register a desire to usethe heart rate monitor for the purpose of authenticating payments aheadof time so that server 110 knows to check for it. Application 106 mayuse an application programming interface on wearable device 102 toobtain information about vital signs, such as heart rate data, determinewhether it is present or not, and then use that as a trigger to approveor deny the payment.

FIG. 2 is a diagram of system 200 for using a wearable device 202,according to an example embodiment. System 200 may include componentssimilar to those shown and described in system 100 of FIG. 1 . System200 may further include a mobile device 204. Mobile device 204 may be indata communication with wearable device 202 and server 206. In variousexamples, mobile device 204 may be an iPhone®, iPod®, or iPad® fromApple or any other mobile device running Apple's iOS® operating system,any device running Microsoft's Windows® Mobile operating system, anydevice running Google's Android® operating system, and/or any othersmartphone, tablet, or any kind of mobile device running any kind ofoperating system.

Mobile device 204 may be configured to conduct a transaction with server206, by installing an application on mobile device 204, visiting awebsite, or using some other configuration. Accordingly, mobile device204 may send a request for an indication of the absence or presence ofhealth data from wearable device 202, receive the indication, andforward the indication to the server 206 to authenticate thetransaction. For example, when wearable device 202 is being worn by awearer, transactions will be approved and when wearable device 202 isnot being worn is off, transactions will be denied. In this way, themere presence or absence of the signal may be used to inform server 206in the decision of whether to authenticate the transaction.

FIG. 3 is a diagram of a system 300 for using a user device 302,according to an example embodiment. System 300 may include one or moreservers 306 in data communication with a user device 302 and a point ofsale (POS) terminal 304. User device 302 may be similar to wearabledevice 102 as shown and described in FIG. 1 and/or similar to mobiledevice 204 as shown and described FIG. 2 , or a combination of the two.In an example where user device 302 is similar to wearable device 102 asshown and described in FIG. 1 , a wearable device may communicatewirelessly with server 306. In an example where user device 302 issimilar to mobile device 202 as shown and described in FIG. 2 , awearable device, such as a fitness tracker (not shown) may communicatewirelessly with server 306 via user device 302.

POS terminal 304 may be any device used to process payments in any timeand at any place where a retail transaction may be completed. At POSterminal 304, a merchant may calculate the amount owed by the customer,indicate that amount, prepare an invoice, indicate payment options tothe customer, and complete the transaction. For example, a card holdermay put a credit card in a card scanner on POS terminal 304, and thenPOS terminal 304 may send a processing request to one or more servers306, which may be associated with the company of the card, (e.g., VISA®,MasterCard®, etc.) and the company may send the request to the issuingbank, which may also be a part of servers 306. The server 306 of theissuing bank may check if there are enough funds in the card holder'saccount, if the card is registered, and if the card holder hasregistered user device 302 to be used to authenticate payment usingheart rate data from a fitness tracker worn by the card holder. Server306 may send a signal either to user device 302 or POS terminal 304requesting authentication. In response, user device 302 may send asignal indicating the presence of heart rate data. The transaction maythen be approved or denied based on the presence or absence of heartrate data at POS terminal 304.

FIG. 4 is a diagram of a system 400 for using a user device 402,according to an example embodiment. In system 400, user device 402 mayinclude a health monitor 404, data storage 406, an applicationprogramming interface (API) 408, an application 410, a user deviceidentifier 412, and an anonymous background queue 414. For example, userdevice 402 may be a smart watch, a fitness tracker or any like type ofdevice.

Health monitor 404 on user device 402 may include sensors 416 andassociated software 418 that may enable health monitor 404 to obtainhealth information about a wearer of the user device 402. Health monitor404 may include, for example, a heart rate monitor for a wrist or cheststrap or a fitness tracker. Sensors 416 may be any type of sensor, forexample, a chest strap may include an electrode pad and transmitter anda wristband fitness tracker may include an optical heart rate monitor.The optical heart rate monitor may have a pulse sensor that shines lightfrom a small light-emitting diode (LED) on the underside of the fitnesstracker onto the skin of the wrist to determine a pulse reading fromblood following through the wrist. Software 418 may perform one or morehealth monitoring functions associated with health monitor 404, forexample, monitoring vital signs, tracking fitness activity, sleepquality and other health monitoring functions.

Data storage 406 on user device 402 may store the health information asuser health data 420. Data storage 406 may be a read-only memory,write-once read-multiple memory or read/write memory, e.g., RAM, ROM,and EEPROM. For example, a fitness tracker may have data storage 406that includes heart rate data associated with a heart rate monitor alongwith other health data.

API 408 on user device 402 may enable health monitor 404 to share userhealth data 420 with other applications, such as application 410,executing on user device 402. For example, a payment application on asmart watch may be set up to authenticate a transaction when the smartwatch detects a heart rate. The payment application may use API 408 toaccess user health data 420 and interface with health monitor 404 todetermine whether a heart rate is detected and send this information toserver 426, mobile device 430 or POS terminal 442.

Application 410 on user device 402 may include a query 422, a signal 424and an update 432. Application 410 may use one or more queries 422 toobtain user device identifier 412 and user health data 420. Application410 may use health data for a purpose other than monitoring health data.For example, in response to a request to verify a payment, application410 may send user device identifier 412 and signal 424 to server 426,where signal 424 indicates the presence or absence of requisite healthdata. As referred to herein, requisite health data may refer to thoseportions of user health data 420 that may be used for various purposesachieved by application 410, which may or may not be related to generalhealth monitoring functionality. For example, application 410 may be apayment application on a smart watch. Upon receipt of user deviceidentifier 412 and signal 424 indicating the presence or absence of therequisite health data, server 426 may identify a user account 428 basedon user device identifier 412 and either enable transactionauthentication if the signal 424 indicates the presence of health dataor disable transaction authentication if the signal indicates theabsence of health data. User device identifier 412 uniquely identifiesuser device 402. For example, user device identifier 412 may be asequence of characters or code that uniquely identifies a smart watch.For example, a user may set up his or her smart watch so that a creditcard purchase, wire transfer, bill pay or any other financialtransaction will only be approved when it is made while the user iswearing his or her smart watch. The user may authenticate a purchase,wire transfer, bill pay or any other financial transaction by uniquelyidentifying the smart watch and providing evidence of health data, suchas a pulse taken by the smart watch.

System 400 may further include mobile device 430, which may bewirelessly connected to user device 402. Mobile device 430 may besimilar to mobile device 204 as shown and described in FIG. 2 . Userdevice 402 may transmit user device identifier 412 and signal 424indicating the presence or absence of the requisite health data tomobile device 430. Upon receipt of user device identifier 412 and signal424 indicating the presence or absence of the requisite health data,mobile device 430 may transmit user device identifier 412 and signal 424indicating the presence or absence of the requisite health data toserver 426. For example, a user may use a smart watch in combinationwith a mobile phone to approve a purchase, wire transfer, bill pay orany other financial transaction by uniquely identifying the smart watchand providing evidence of a heart rate and/or pulse taken by the smartwatch.

Query 422 may be a long-running query that executes on an anonymousbackground queue 414 on user device 402. Application 410 may receive anupdate 432 when the requisite health data changes, and upon receipt ofupdate 432, application 410 may transmit user device identifier 412 anda change of status signal 424 to server 426. For example, an applicationon a smart watch may periodically monitor the user's heart rate and/orpulse in the background, while other functions of the smart watch may beoperating. The smart watch application may include alerts or updateswhen it detects certain changes in the user's heart rate and/or pulse,such as when the user puts on or takes off the watch.

In an example embodiment, user device 402 may be, for example, a smartwatch, such as an Apple Watch®, smart clothing, or a medical devicehaving sensors 416 that may detect and store vital signs as healthinformation. As referred to herein, vital signs may be any healthinformation that helps people to monitor their health status forathletic activity, fitness, sports, wellness, or medical assessment,diagnostics, or treatment, such as bodily motion, heart rate, stepcount, activity classification, blood pressure, respiration rate, bloodoxygen saturation, blood glucose, skin perspiration, body temperature,and other biometrics or sensor measurements.

In an example embodiment, signal 424 indicating the presence or absenceof the requisite health data may be a Boolean flag. Signal 424 may bestored in various other kinds of data structures, such as a number ordatabase record and may be transmitted in various types of messages overany type of communication networks that may be used to connect userdevice 402, mobile device 430, server 426, backend system 434 and/or POSterminal 442. For example, when a user is using a payment application ona mobile phone to make a purchase, wire transfer, bill pay or any otherfinancial transaction, the financial transaction may be authenticated byuniquely identifying a health monitor and/or fitness tracker being wornby the user and sending a quick indication that the health monitorand/or fitness tracker is detecting a heart rate to allow the financialtransaction to be approved in a matter of seconds.

In an example embodiment, user device 402 and server 426 may communicatethrough request and response messages during a device registrationprocess 426 to register 436 user device 402 with server 426. During userdevice registration process 426, server 426 may receive user deviceidentifier 438 from user device 402 and store registered user deviceidentifier 438 at server 426, thereby associating user device 402 withuser account 428 of the account holder. For example, a user may registera smart watch to be used to verify purchases, wire transfers, bill payor any other financial transactions made with a particular credit cardin order to prevent fraudulent transactions. On their mobile device, theuser installs an application that is associated with the issuing bank toregister the smart watch with its unique device ID and set a preferenceto authenticate payments made with the card using the smart watch. Afterregistration, the bank may authenticate payments made with the cardaccording to the user's preference. After registration, the user maychange their preference by opening the application to toggle the featureto use vital signs for transaction approval on or off.

In an example embodiment, upon receipt of user device identifier 412 andsignal 424 indicating the presence or absence of the requisite healthdata, server 426 may compare the received user device identifier 412with the registered user device identifier 438, and, if the receiveduser identifier 412 and registered user identifier 438 are the same,either enable transaction authentication if the signal indicates thepresence of health data or disable transaction authentication if thesignal indicates the absence of health data. For example, a smart watchmay send its unique device ID and an indication that heart rate and/orpulse data was detected in response to a request to authenticate atransaction made with a credit card. The indication that heart rate datawas detected may be a flag or some kind of message containing theindication sent from the smart watch or mobile device 430.

In an example embodiment, server 426 may receive a transaction request440 from point of sale terminal 442, identify user account 428 based oninformation received with transaction request 440, determine whethertransaction authentication is enabled or disabled for the user account,and either transmit signal 444 approving transaction request 440 iftransaction authentication is enabled or transmit a signal 444 denyingtransaction request 440 if transaction authentication is disabled. Forexample, a user may swipe a card on a card reader in a store and thecard reader may send a transaction request to a banking backend system.The banking backend system may determine the user's account and check ifthe user had set up a preference to authenticate transactions with thiscard using a wearable device, and, if so, use information about whetherthe wearable device is enabled or disabled in some way to approve ordeny the purchase at the store.

In an example embodiment, developer tools and/or platform-based servicesmay be used for various types of user devices. For example, an AppleWatch® may use the Apple® developer HealthKit. HealthKit may be used forrequesting user permission to read, write and/or share, for example,heart rate samples and taking steps to maintain the privacy of userhealth data. Heart rate sample data may represent data at a particularpoint in time. Data structures such as sample classes to hold the sampledata may include device, type, start date, end date, quantity samples,and correlations. The device may be the hardware device that generatedthe data stored in this sample. The type may be the sample type, such asa sleep analysis sample, a height sample, or a step count sample. Thestart date may be the sample's start time. The end date may be thesample's end time. If the sample represents a single point in time, theend time should equal the start time. If the sample represents datacollected over a time interval, the end time should occur after thestart time. Quantity samples may be data that can be stored as numericvalues. Quantity samples may include the user's height and weight, aswell as other data such as the number of steps taken, the user'stemperature, and their pulse rate. Correlations may be composite datacontaining one or more samples and may be used to represent food andblood pressure data. IPhone® and Apple Watch® may each have their ownHealthKit store and data may be automatically synced between the phoneand watch. To save space, old data may be periodically purged from AppleWatch®.

For example, when reading data from HealthKit, a long-running query mayrun on an anonymous background queue. Long-running queries may continueto run in the anonymous background queue and provide updates wheneverchanges are made to the HealthKit store. An observer query may be along-running query that monitors the HealthKit store and provides alertsfor any changes to matching samples.

In an example embodiment, developer tools or platform-based services maybe used for a fitness tracker such as FitBit®. A heart-rate API, whichhas a class HeartRateSensor and a HeartRateSensor API may be used torequest permission to use query a heart rate monitor that measures therate of a person's heartbeat. The API may provide access to the heartrate data, including a Boolean flag that indicates if the heart ratemonitor is activated or not, event handlers, an interfaceBatchedHeartRateSensorReading for reading heartrate and timestamp, andan interface HeartRateSensorReading for real-time measurement from theheart rate monitor for reading heartrate and timestamp.

In other example embodiments, other developer tools or platform-basedservices may be used with IoT devices, wearable devices, and variousother user devices for generating health data that may be used by anapplication for a different purpose.

FIG. 5 is a flowchart illustrating a method 500 for using a user device,according to an example embodiment. Method 500 begins at block 502. Inblock 502, a server may receive a transaction request from a point ofsale terminal. For example, when a card holder pays a merchant for apurchase with a credit card, the point of sale terminal may process thetransaction over a network including a bank backend server. As part ofprocessing, the bank backend server may receive a message containing thetransaction request. The transaction request may include the credit carddetails, merchant information and the payment amount. Credit carddetails may include the credit card number, card expiration date,billing address, card security code, etc. For example, when a user paysa merchant using a payment application on a smart watch, the point ofsale terminal may processes the transaction so that a server may receivea message containing the transaction request and including similarinformation. For example, when a user pays a merchant using a paymentapplication on a mobile phone, the point of sale terminal may processesthe transaction so that a server may receive a message containing thetransaction request and including similar information.

In block 504, the server may determine the user account associated withthe transaction request. For example, a bank backend server may usecredit card details in the transaction request to match to the cardholder's account information stored in a database accessible by the bankbackend server. For example, a bank backend server may use the creditcard number from the transaction request as keys to index into or locatethe card holder's account among the bank records. For example, a serverin a credit card network may use credit card details in the transactionrequest to match to the card holder's account information stored in adatabase accessible by the credit card network.

In block 506, the server may determine whether the user account hasbiometric transaction authorization enabled. If the card holder does nothave biometric transaction authorization enabled, then method 500 endsat 510. For example, the bank backend server may have previously storedinformation in the card holder's account information indicating that thecard holder had enabled biometric transaction authorization. Thisinformation may include a unique identifier for a user device to providebiometric transaction authorization that was stored when the card holderregistered the user device. For example, the user may register a fitnesstracking device with a server and choose an option to use a biometricthat is associated with the fitness tracking device to authenticatecredit card purchases. For example, the fitness tracking device mayprovide heart rate, skin perspiration, skin temperature, and otherbiometrics that may be used for this and other purposes.

If in block 506 the user account has biometric transactionauthentication enabled, then in block 508, the server may determinewhether biometric data is being received from a known user deviceassociated with the user account. For example, the bank backend serverreceives one or more messages from the user device including the uniqueidentifier of the user device and biometric data from the user device.The bank backend server verifies the unique identifier of the userdevice by comparing the received unique identifier of the user devicewith the stored unique identifier of the user device in the cardholder'saccount. If they are the same, then biometric data is being receivedfrom the known user device. For example, a user had previouslyregistered a smart watch with a server, including providing a uniquesmart watch identifier, which was stored by the server and associatedwith the user account. For example, a user had previously registered amedical device with a server, including providing a unique identifierassociated with the medical device, which was stored by the server andassociated with the user account.

In block 512, if biometric data is being received from the known userdevice, the server may authorize the transaction to the point of saleterminal. For example, a bank backend server may authorize thetransaction by transmitting an authorization message to the point ofsale terminal in response to the transaction request message from thepoint of sale terminal. For example, a bank backend server may receivebiometric data from a medical device, such as a glucose monitor, whichmay provide some indication of glucose monitoring, and, in response, theserver may authorize the transaction. For example, a bank backend systemmay authorize a transaction after receiving voice data from a headsetdevice.

In block 514, if biometric data is not being received from the knownuser device, the server may deny the transaction to the point of sale.The bank backend server may check the last time a signal containingbiometric data was received and use a measure of how stale the biometricdata needs to be before transactions are declined. For example, if asignal is not received for x time period, then transactions will bedenied until a new signal comes in. For example, the bank backend servermay deny the transaction by transmitting a transaction denial message tothe point of sale terminal in response to the transaction requestmessage from the point of sale terminal. For example, a server mayreceive a message from a fitness tracker indicating the absence ofbiometric data and, in response, the server may deny the transaction.For example, a user might not be wearing a smart watch that wasregistered with the server and the server will receive an indicationthat the smart watch is not detecting a pulse so that the server maydeny the transaction.

FIG. 6 is a flowchart illustrating a method 600 for using a user device,according to an example embodiment. Method 600 begins at block 602. Inblock 602, the user device may be associated with a user account. Forexample, a smart watch may be capable of sensing health information ofthe user and transmitting that health information to a transactionauthorization system. The transaction authorization system may include aserver, a bank backend system and/or a point of sale terminal. The usermay associate the smart watch with the user account by using a mobilephone to access an application that includes a way to register the smartwatch with the bank backend system. The application may includeproviding a unique identifier associated with the smart watch to thebank backend system and providing credit card information to identify auser account to the bank backend system. The application may includeselecting an option to use the smart watch to authenticate transactionmade with that credit card. For example, a bank backend system may storeinformation about the user account in a database, where the user accountincludes a record associating a fitness tracking device with the useraccount for the purpose of authenticating future transaction. Forexample, a smart watch may include an application for making paymentsthat associates the smart watch with a payment account and may storethis information in data storage on the smart watch or send theinformation for storage to a bank backend system or a mobile device. Forexample, a mobile device may include an application for making paymentsthat associates a medical device with a payment account and may storethis information on the mobile device or send the information forstorage on a server.

In block 604, a user device may periodically provide biometricinformation that indicates whether vital signs of the user are beingdetected by the user device. Some of this biometric information maylater be received by a server in a message sent by the user device. Forexample, a heart rate monitor may use a sensor to periodically read theheart rate of the user and store the readings in a data storage on theheart rate monitor. An application executing on the heart rate monitormay use an API to access the heart rate reading information. Theapplication may later send a portion of the heart rate readinginformation to a server in a message. For example, a smart watch may beconfigured to monitor a pulse at the wrist of the wearer and store pulsereading data on the smart watch. An application executing on the smartwatch may use an API to receive an alert when the pulse reading datachanges on the smart watch. The application may later send an indicationof a pulse reading change to a server in a message. For example, amedical device may be configured to periodically detect and storebiometric information on the medical device. An application executing onthe medical device may use an API to access the biometric information onthe medical device. The application may later send a portion of thebiometric information to a server in a message.

In block 606, an indication of whether vial signs of the user are beingdetected by a user device may be stored in a database or another type ofdata storage. For example, a smart watch may store an indication ofwhether a pulse is being detected at the wrist of the wearer in a memoryon the smart watch. For example, a fitness tracker may store anindication of whether steps are being detected in a memory on thefitness tracker. For example, a medical device may store an indicationof glucose monitoring in a memory on the medical device.

In block 608, a transaction request may be received from a point of saleterminal. For example, a card holder may swipe a card at a point of saleterminal to make a purchase at a restaurant. The point of sale terminalmay process the purchase, resulting in a bank backend system receivingthe transaction request, including credit card information, merchantinformation, and purchase amount, etc. For example, a user may use apayment application on a mobile device to request and pay for a serviceat a point of sale terminal. When the point of sale terminal processesthe payment request, a server may receive a transaction request directlyor indirectly from the point of sale terminal. For example, a creditcard network may forward the transaction request to a server of anissuing bank.

In block 610, a server may determine a user account associated with atransaction request. For example, a banking back end server may receivea transaction request containing credit card information, paymentamount, billing address, etc., and use this information to match to theappropriate user account in stored account records that are accessibleby the server. For example, a server may query a database using a creditcard number as an index. For example, a server may use a third partyapplication to determine the user account associated with a transactionrequest. For example, a server may receive a transaction requestcontains information that uniquely identifies a user account, accordingto records at the server.

In block 612, a user account in a database is accessed to determinewhether vital signs of a user are being detected by a user device. Forexample, an application executing on a smart watch may access a memoryon the smart phone to determine whether a pulse was recently detected onthe wrist of the user and then send a message to a server with theresults. The server may receive the message and store a flag indicatingwhether vital signs of the user were being detected. The flag may bestored in a user account record in a database or in temporary storagefor use in processing a current transaction. For example, a serverprocessing a transaction authorization request may access a user accountin a database to determine whether vital signs are being detected by auser device that was previously registered by the user. For example, aserver may access a user account in a database to determine whether auser has selected an option of authenticating transactions using vitalsigns detected by a user device before processing a transactionauthorization request.

In block 614, a transaction request is authorized if the indication isthat vital signs are being detected and denied the transaction if not.If the transaction is denied, then the method 600 ends. For example, abank backend server may send a message to a point of sale terminal thatcontains a transaction authorization after receiving a message from asmart watch indicating that a pulse was recently detected on the smartwatch in response to an authentication request message sent by the bankbackend server to the smart watch. For example, a server may authorize atransaction request by sending a message to a point of sale terminalupon receiving a message from a mobile phone indicating that vital signsare being detected on a user device. For example, a server may deny atransaction request upon receiving a message from a fitness trackerindicating that a heart rate is not being detected.

In block 616, a transaction authorization response may be transmitted toa point of sale terminal. For example, a bank backend server may send atransaction authorization response to a point of sale terminal. Forexample, a credit card network may send a transaction authorizationresponse to a point of sale terminal, where the transactionauthorization response was received and forwarded from another server.

FIG. 7 is a flowchart illustrating a method 700 for using a user device,according to an example embodiment. The method 700 begins at block 702.In block 702, user account information may be stored. For example, abank backend system may store information about a user's credit cardaccount in a record in a database. This information may include thecredit card number, the user's name and billing address, etc. Thisinformation may also include information about whether the card holderelects to authenticate transactions using health information from a userdevice, such as a smart watch. For example, a user may register a smartwatch with a bank backend system so that it may be used to authenticatefuture transactions. For example, each user account may have useraccount information that includes: information to identify the accountholder, an account holder wearable device identifier, and a flag thatindicates whether transactions are to be approved or denied based on therespective presence or absence of a vital sign of the account holderthat is detected by a wearable device identified by the account holderwearable device identifier.

In block 704, an application may be provided on a wearable device. Forexample, an application may be provided for execution on a wearabledevice that includes a health monitor. The application may query, via anapplication programming interface to the health monitor, the wearabledevice to obtain a wearable device identifier and health data thatindicates the presence or absence of a vital sign of the wearer of thewearable device. For example, a payment application may be installed ona smart watch that accesses health data monitored by smart watch throughan application programming interface. For example, a fitness tracker mayhave an application provided that allows access to heart rate monitoringdata. For example, a medical device may have an application providedthat allows access to glucose monitoring data.

In block 706, the wearable device identifier and the presence or absenceof vital signs may be transmitted wirelessly to a backend system. Forexample, a smart watch may wirelessly transmit the smart watch's uniqueidentifier and health data that indicates the presence or absence of thewearer's pulse to a backend system in response to a request forauthenticating a transaction. For example, a fitness tracker may send amessage to a backend system that includes a unique identifier for thefitness tracker and an indication of the presence or absence of thewearer's heart rate during a recent period of time. For example, amedical device may send a message to a backend system that includes aunique identifier for the medical device and an indication of thepresence or absence of recent glucose monitoring data.

In block 708, a backend system may receive a wearable device identifierand the presence of absence of a vital sign. For example, the backendsystem may receive a message from a smart phone including a uniqueidentifier and an indication of the presence or absence of heart ratemonitoring data. For example, the backend system may receive a messagefrom a fitness tracker that includes a unique identifier and anindication of the presence or absence of motion detection data. Forexample, the backend system may receive a message from a mobile phonethat includes a unique identifier or a medical device and an indicationof the presence or absence of temperature data.

In block 710, a decision may be made about whether the wearable deviceidentifier matches user account information. If it does not match, thenthe method 700 ends. For example, a processor at a backend system maymatch a smart watch identifier received in a message from the smartphone with the identifier of a previously registered smart watch that isstored at the backend system in a database record for an account holderassociated with the registered smart watch. For example, a server maydetermine whether a fitness tracking device identifier sent in a messageby the fitness tracking device matches the stored fitness trackingdevice identifier for a particular account holder identified in atransaction authorization request message received by the server. Forexample, a server may determine whether a medical device identifier sentin a message by the medical device matches a stored medical deviceidentifier for an account holder identified in a transactionauthorization request message received by the server from a point ofsale terminal. The account holder may be determined by the server fromcredit card information and billing information in the transactionauthorization request message and by matching that information toaccount records stored in a database accessible by the server. If thereceived medical device identifier and the stored medical deviceidentifiers are different, then the method 700 ends.

In block 712, it is determined whether a vital sign is present. If thewearer's wearable device identifier matches the account holder wearabledevice identifier: access, using the processor at the backend system,the account holder user account, and set, using the processor at thebackend system, the flag stored in the account holder user account thatindicates whether transactions are to be approved or denied based on thereceived health data that indicates the presence or absence of thewearer's vital sign.

FIG. 8 is a flowchart illustrating a method 800 for using a user device,according to an example embodiment. Method 800 begins at block 802. Inblock 802, a backend system receives a transaction approval request froma point of sale terminal. For example, the transaction approval requestmay include credit card information, transaction amount information,merchant information, the cardholder's billing address information, etc.In some embodiments, the backend system may receive the transactionapproval request indirectly from the point of sale terminal andinformation may be forwarded from a credit card network. For example,the transaction approval request may be part of or in response to apayment authorization request.

In block 804 a backend system may identify a user account. A processorat the backend system may identify an account holder's account based onstored information already received about the user account whileauthenticating the transaction with health data from a user device.

In block 806, a backend system transmits a message to a point of saleterminal either approving or denying the transaction. A processor at thebackend system may query the account holder user account to determinewhether a flag stored in the account holder user account indicateswhether to approve or deny the transaction. The processor at the backendsystem may transmit, based on the query result, a signal approving ordenying the transaction to the point of sale terminal. The query may bean application executed by the processor to operate on a databaseholding user account records. The database may be accessible by thebackend server or stored in memory on the backend server.

FIG. 9 is a flowchart illustrating a method 900 for using a user device,according to an example embodiment. Method 900 begins at block 902. Inblock 902, an application is provided to a mobile device. The mobiledevice may be wirelessly connected to a wearable device. In block 904,the application on the mobile device may receive, via the wirelessconnection to the wearable device, the wearer's wearable deviceidentifier and health data that indicates the presence or absence of thewearer's vital sign to the backend system. In block 906, the applicationmay wirelessly transmit the received wearer's wearable device identifierand health data to the backend system. For example, a user may install apayment application on a mobile phone that is wirelessly connected to asmart watch. The application may provide a way for the user to registerthe smart watch, including sending a smart watch unique identifier to abackend system. The application may further provide a way for the smartwatch to send health data to the backend system that indicates thepresence of absence of a pulse on the wrist of the person wearing thesmart watch to authenticate a future transaction made with theapplication.

FIG. 10 is a flowchart illustrating a method 1000 for using a userdevice, according to an example embodiment. Method 1000 begins at block1002. In block 1002, an application may execute a query on a wearabledevice via an application programming interface. The query may be along-running query that executes on an anonymous background queue on thewearable device. For example, a payment application on a smart watch mayinclude a query from an API on the smart watch that monitors a heartrate periodically over a long period of time while other applicationsare running on the smart watch. The query may read and store heart ratedata on the smart watch for future use for a payment-related purpose.

In block 1004, the application may receive an update from an applicationprogramming interface when the health data changes. For example, a smartwatch application monitoring heart rate data, may be configured toreceive alerts from another application when there is a change in statusof the heart rate data, such as when the smart watch is put on or takenoff the wrist of the user.

In block 1006, the application may transmit a wearable device identifierand a change of status signal to the backend system. For example, asmart watch application may send a smart watch unique identifier and amessage including an indication that the heart rate data stopped beingmonitored when, for example, the user took off the smart watch or anindication that the heart rate data started being monitored when theuser put on the smart watch.

FIG. 11 is a flowchart illustrating a method 1100 for using a userdevice, according to an example embodiment. Method 1100 begins at block1102. In block 1102, a registration interface may be provided to anaccount holder. For example, a user may use a mobile phone to install abanking application that includes a way to register a wearable device tobe used to authenticate payments from a particular credit card account.The banking application may include a registration interface forreceiving and transmitting messages to a backend system via a wirelessnetwork. The messages may include a unique identifier for the wearabledevice that may be stored at the backend system to be used toauthenticate future transactions. In block 1104, the backend server maystore the account holder's wearable device identifier in the accountholder's user account and/or in credit account records in a databaseaccessible by the backend system. Other similar interfaces, e.g., webinterfaces, associated with the backend system may be used to register awearable device in a similar manner.

In block 1106, the backend server may store account holder preferences,such as a preference to use the wearable device to authenticatetransactions made with a particular credit card account. For example,the banking application installed on a mobile phone may include aregistration interface that includes a way to turn on an option to use awearable device to authenticate transactions for a particular creditcard so that the backend server will either approve or deny transactionsbased on the presence or absence of a vital sign from the wearabledevice around the time that a transaction is being processed for thatcredit card. The backend server may receive a message from theapplication on the mobile phone requesting to turn on the option to usethe wearable device to authenticate transaction for that credit card.The backend server may then store information indicating that theaccount holder wants to use the wearable device to authenticatetransaction in an account record associated with that credit card andstored in a database at the backend server.

FIG. 12 is a flowchart illustrating a method 1200 for using a userdevice, according to an example embodiment. Method 1200 begins at block1202. In block 1202, a smart watch senses a wearer's heart rate. Forexample, a smart watch being worn by a wearer uses its optical heartrate sensors and associated software on the smart watch to detect andcalculate the wearer's heart rate. For example, a smart watch mayinclude an application that is capable of monitoring the wearer's heartrate and sending messages to a backend system that indicate the presenceor absence of the wearer's heart rate. In block 1204, a backend systemsets a flag to deny transactions when they smart watch is not sensingthe wearer's heart rate. For example, the wearer may install anapplication on a smart watch that includes a registration interface. Theregistration interface may have a way for the smart watch to sendmessages to the backend system to register the smart watch. Theregistration interface may have a way for the smart watch to sendmessage to the backend system to set a preference to approve or denytransactions based on the respective presence or absence of a vitalsign, such as heart rate from the smart watch at the time of thetransaction. Upon receiving the message setting this preference, thebackend server may store a flag indicating this preference in an accountassociated with the wearer.

In this description, numerous specific details have been set forth. Itis to be understood, however, that implementations of the disclosedtechnology may be practiced without these specific details. In otherinstances, well-known methods, structures and techniques have not beenshown in detail in order not to obscure an understanding of thisdescription. References to “some examples,” “other examples,” “oneexample,” “an example,” “various examples,” “one embodiment,” “anembodiment,” “some embodiments,” “example embodiment,” “variousembodiments,” “one implementation,” “an implementation,” “exampleimplementation,” “various implementations,” “some implementations,”etc., indicate that the implementation(s) of the disclosed technology sodescribed may include a particular feature, structure, orcharacteristic, but not every implementation necessarily includes theparticular feature, structure, or characteristic. Further, repeated useof the phrases “in one example,” “in one embodiment,” or “in oneimplementation” does not necessarily refer to the same example,embodiment, or implementation, although it may.

As used herein, unless otherwise specified the use of the ordinaladjectives “first,” “second,” “third,” etc., to describe a commonobject, merely indicate that different instances of like objects arebeing referred to, and are not intended to imply that the objects sodescribed must be in a given sequence, either temporally, spatially, inranking, or in any other manner.

While certain implementations of the disclosed technology have beendescribed in connection with what is presently considered to be the mostpractical and various implementations, it is to be understood that thedisclosed technology is not to be limited to the disclosedimplementations, but on the contrary, is intended to cover variousmodifications and equivalent arrangements included within the scope ofthe appended claims. Although specific terms are employed herein, theyare used in a generic and descriptive sense only and not for purposes oflimitation.

This written description uses examples to disclose certainimplementations of the disclosed technology, including the best mode,and also to enable any person skilled in the art to practice certainimplementations of the disclosed technology, including making and usingany devices or systems and performing any incorporated methods. Thepatentable scope of certain implementations of the disclosed technologyis defined in the claims, and may include other examples that occur tothose skilled in the art. Such other examples are intended to be withinthe scope of the claims if they have structural elements that do notdiffer from the literal language of the claims, or if they includeequivalent structural elements with insubstantial differences from theliteral language of the claims.

1-20. (canceled)
 21. A system, comprising: a server, comprising aprocessor and a memory, wherein the server: stores a user account of theuser, wherein the user account comprises user account information, auser device identifier and a user preference, wherein the userpreference is an indication to enable a biometric transactionauthentication with a user device; receives, from the user device, theuser device identifier and a signal indicating the presence or absenceof the requisite health data; identifies the user account based on thereceived user device identifier; determines whether the received signalindicates the presence or absence of the requisite health data;receives, from a point of sale terminal, a transaction request of thetransaction; identifies the user account based on information receivedwith the transaction request; determines whether biometric transactionauthentication is enabled or disabled for the user account; and approvesthe transaction request based on a determination that the biometrictransaction authentication is enabled by transmitting, to the point ofsale terminal, an authorization message based on; or denies thetransaction request based on a determination that the biometrictransaction authentication is disabled by transmitting, to the point ofsale terminal, a transaction denial message.